Financial reporting as mandated in government regulations is complex. The rules require various links among the data elements, provide overlapping definitions of both the data elements and their links, define required report outputs, report formats and arbitrary methods to rename and reorganize the financial information that flows from the source companies to the viewers of the reports.
The data for financial reports conventionally originate in spreadsheets or word processing text forms prepared by company agents in applications such as Microsoft's Excel spreadsheet software or Microsoft's Word word processor software. These data must be reconfigured into reporting formats that meet government and regulatory reporting requirements issued by the U.S. Securities and Exchange Commission (“SEC”) along with certain accounting standards set by non-governmental organizations (“NGOs”) such as the Financial Accounting Standards Board (“FASB”).
To reconcile and harmonize financial data, a markup system known as eXtensible Business Reporting Language (“XBRL”), built on the general eXtensible Markup Language platform (“XML”), has been adopted by many entities responsible for providing and presenting financial reports. A specification for XBRL is developed and published by XBRL International, Inc., which states:                “XBRL is a powerful and flexible version of XML which has been defined specifically to meet the requirements of business and financial information. It enables unique identifying tags to be applied to items of financial data, such as ‘net profit’. However, these tags are more than simple identifiers. They provide a range of information about the item, such as whether it is a monetary item, percentage or fraction. XBRL allows labels in any language to be applied to items, as well as accounting references or other subsidiary information.        “XBRL can show how items are related to one another. It can thus represent how they are calculated. It can also identify whether they fall into particular groupings for organizational or presentational purposes. Most importantly, XBRL is easily extensible, so companies and other organizations can adapt it to meet a variety of special requirements.        “The rich and powerful structure of XBRL allows very efficient handling of business data by computer software. It supports all the standard tasks involved in compiling, storing and using business data. Such information can be converted into XBRL by suitable mapping processes or generated in XBRL by software. It can then be searched, selected, exchanged or analyzed by computer, or published for ordinary viewing.”        
XBRL provides a system of tagging the data elements it provides in a financial report. This means that in an XBRL report with tags embedded in it, a PC, laptop, tablet, or other computing device can identify and appropriately process the data by referencing one or more tags corresponding to the data.
In general, XBRL defines a set of XML based data structures, conventions and terminology to represent financial and other data. Each important data object within a financial report is presented as a “fact”. For example, the number representing the “current notes payable” by a reporting entity would be considered a “monetary fact” while a description of the account principals employed would be a “text fact”. To identify a fact in a meaningful and computer readable form, the fact is contained within an XML “element”. That element may then be identified from a large set of similarly predefined elements. For example, in the US, a set of accepted elements has been created representing financial principles as defined by the Generally Accepted Accounting Principles or US-GAAP. Custom elements, if desired, may be defined by the author/preparer due to the flexibility built into XBRL. In order for the fact to have meaning for a specific time, the fact is also identified by a “context”. Contexts can be as simple as a single date or as complex as a date range qualified by a dimension to add depth to facts. A provision within XBRL allows authors to describe one or more “presentations”. Presentations provide information for any third party rendering software to be able to group elements and “labels” for the eventual visual display of facts in a manner meaningful to a human reader. Labels have a specific relationship or role when associated with a specific element. For example, within one presentation the element “Profit” may have the label “Income (loss)”, whereas on another presentation that tallies net loss carry forwards, the label may have a negated value to show the same data as “Losses”. In such a scenario, the fact may be shown as a negative number on an operating statement and a positive number within a disclosure.
Traditionally, the SEC has required entities to prepare their documents for submission in either plain text (“ASCII filing”) or as HyperText Markup Language (“HTML”). HTML, when combined with certain styling properties (“CSS”), can uniformly represent the majority of formatting for documents to be displayed within common interne browsers such as Internet Explorer, or Mozilla Firefox. With the implementation of XBRL, certain aspects of various forms filed with the SEC must be detailed and tagged as a separate exhibit in XBRL format. The HTML portion of a submission is considered by regulation as the “official” document while the XBRL portion, representing only a specific fraction of the document, is considered “as filed”.
Essentially, XBRL does not affect any additional disclosure by the submitter but does require data to be more clearly identified and computer readable. As such, certain information may be duplicated between the HTML and the XBRL. Further, the SEC now requires that financial statements and certain related notes be tagged using four different levels of detail:
Level I—Each disclosure is tagged as a single block of text;
Level II—Each significant accounting policy is tagged as a single block of text, with tables and other narrative facts broken out as in Levels III and IV;
Level III—Each table is tagged as a separate block of text; and
Level IV—Each fact (i.e., monetary value, percentage, and number) is separately tagged.
Certain factual information set forth in Level I will be duplicated and further refined in Levels II-IV. For example, a table describing various assets of a company will be formatted as block text and mixed with narrative in Level I; broken away from the narrative and set forth as table(s) facts in Level III; and finally have each number detailed as tagged XBRL elements in Level IV. In a typical submission to the SEC, one number may be duplicated in four data areas as well as interdependent on an account basis in one or more areas. For example, a table detailing assets may be: (i) in the official HTML document; (ii) a part of a Level I complete text block describing the assets as a note to the financials; (iii) a part of a table text block in Level III; and, finally (iv) a detailed tagged fact within a presentation identified by an XBRL element and a context (date). The same fact may be used in multiple places within a document. For example, a detailed table of financial “cash” instruments may total to a number that will appear in one or more tables within the note and also appear as line item on a statement such as a balance sheet.
Prior to filing, many reports are “converted” to a commonly acceptable format such as HTML, which may later be distilled into XBRL. Since HTML describes document structure, not data relationships, it is more limited in certain respects than is XBRL or XML, but it is the form in which spreadsheets and word processors commonly produce their outputs. The result is that many translations and mappings may be performed manually to produce a compliant financial report. Thus, simplification, streamlining, and reconciling of all the variations in a report is desirable.
Finally, as a convention that may be used herein, the terms HTML and XHTML are interchangeable. The SEC may accept a limited set of legacy HTML elements for submission of official documents while HTML contained with XBRL must be formatted as XHTML. XHTML is characterized by the use of lower case elements and strict adherence to tag nesting and structure. When used within an XBRL text block, XHTML must be well formed for the document to be accepted. On the other hand, plain HTML requires proper coding and nesting but readers (commonly known as internet browsers) tend to compensate or adjust for errors to allow viewing of a wide variety of poorly coded documents. A poorly formed HTML document will be accepted as an official document filed to the SEC while the same document content contained in XBRL must be well formed.
XBRL, XML and HTML all are based on SGML (“Standard Generalized Markup Language”) where coding information is differentiated from data via the use of chevron characters, ‘<’ and ‘>’, which in turn contain elements, such as a ‘P’ to signify a paragraph element, and attributes, such as ‘ID’ to signify an identifier assignment. Any combination of the “Element-Attribute”, or “Element-Attribute-Attribute . . . ” if an element has more than one attribute available to it, is referred to as a “tag”. Within a tag, characterizing information for the text being marked up is stored between the ‘<’ and ‘>’ characters. An example:
<P ID=“identifier-1”>text being marked up</P>
where “P” is the Paragraph element of HTML, “ID” is the Identifier attribute of the paragraph being presented, “identifier-1” is the value of the Identifier, “text being marked up” is the text of the paragraph, and “</P>” marks the end of the paragraph.
The conventional term “tagging” data implies adding specific tags to identify various sections of data. For HTML, the identified data is typically headings, paragraphs, tables, and cells of data within tables. For XBRL, the identified data is substantially more complex and involves facts, labels, contexts and a variety of other information. HTML is principally designed to represent document structure for human consumption while XBRL is principally designed to represent financial data in the form of both an addressable database and for human presentation.